A computer program can use multiple categories of data storage during execution. Two such data storage categories involve a stack and a heap. The stack is typically an area of memory used for runtime data for methods, such as local variables, method return locations, intermediate results, etc. Alternatively, the heap includes an area of memory reserved for data that is created at runtime, wherein the lifetime of data in a heap typically is not determined by the lifetime of a particular method, whereas the lifetime of data in a stack is limited by the lifetime of the method with which the data is associated. In some approaches, however, a heap may also contain data normally put on the stack.
In addition, during execution, a program may no longer need data that has been allocated in the heap. Therefore, some method is required to reclaim the unneeded memory space from the heap. One method involves explicit program instructions to “free” the unneeded memory.
Another method is called “garbage collection.” Garbage collection generally involves reclaiming the heap memory that is no longer being used by the program. Typically, in a multithreaded program, a heap is shared by multiple program threads. A program thread refers to a part of a program that runs somewhat independently of (e.g., non-sequentially with) other parts of the program. Program threads often share some of their environment with other program threads. For example, individual program threads may be distinguished by the value of their program counters and stack pointers. Program threads may also share a single address space and set of global variables.
However, garbage collection of a shared heap in a multithreaded program typically requires that access to the shared heap by other program threads (i.e., other than the garbage collection thread or threads) be suspended until the garbage collection is complete. Alternatively, all other program threads may be synchronized with one or more garbage collection threads to avoid corruption of the heap. Note: In some approaches, a program thread may perform its own garbage collection. Heap corruption can occur, for example, if a program thread allocates a program object to the shared heap during garbage collection by another thread (e.g., a garbage collector thread). For example, because the garbage collector thread lacks needed information about the new program object (e.g., which other program objects the new program object may reference), the garbage collector thread may inappropriately reclaim the memory associated with the new program object. As such, garbage collection in a multithreaded program traditionally requires synchronizing among the program threads or suspending the execution of the program threads during collection to prevent the program threads from arbitrarily modifying the shared heap during collection.
Both program thread-suspension and synchronization (e.g., forms of rendezvous) significantly contribute to garbage collection latency and impair performance of the program during garbage collection. Particularly for server-type applications with several hundred program threads, such garbage collection latency can present significant performance problems.